Computer processor design is an extremely complex and lengthy process. The design process includes a range of tasks from high-level tasks such as specifying the architecture down to low-level tasks such as determining the physical placement of transistors on a silicon substrate. Each stage of the design process also involves extensive testing and verification of the design through that stage. One typical stage of processor design is to program the desired architecture for the processor using a register transfer language (RTL). The desired architecture is represented by an RTL specification that describes the behavior of the processor in terms of step-wise register contents. The RTL specification models what the processor does without describing the physical circuit details. Thus, the processor architecture can be verified at a high level with reference to the RTL specification, independent of implementation details such as circuit design and transistor layout. The RTL specification also facilitates later hardware design of the processor.
Manually verifying the RTL specification of the processor architecture is prohibitively complex during the design of a modern microprocessor. Therefore, multiple test cases are typically generated to test the design. Each test case contains input instructions and may also contain the desired results or outputs. Once created, the test cases may be executed on a simulation of the RTL specification (often compiled to increase speed) and the results analyzed. Through that analysis, errors in the RTL specification, and potentially the processor architecture design, may be identified.
Many processors use multiple processor cores that execute instructions during processor operation. Cores of such processors are connected by an interface, such as a point-to-point (P2P) interface or a front side bus (FSB) interface, typically on a single chip. With such a configuration, the processor may be operated in a “lockstep” mode in which two or more of the processor cores (a master core and one or more slave cores) execute the same instruction stream each clock cycle. Given that the behavior of the cores is deterministic, the same output should result from each processor core operating in lockstep mode. One advantage of operating in lockstep mode is that if one of the cores experiences an error (e.g., a manufacturing defect, a stuck-at fault, a soft error from an alpha particle, a transient electrical failure, etc.), the other core(s), at least in theory, can continue to execute so that the processor can continue to operate. Assuming that the core that experienced the error has not failed completely, the operating system may be able to resynchronize that core so as to resume normal lockstep operation.
A “lockstep block” may be provided within the verification system that logically resides between the modeled processor cores and their interfaces. In such a case, the lockstep block can monitor outputs of the cores (e.g., data and/or error signals) such that the lockstep block can identify when core errors occur. If a self-detected (i.e., core-reported) error occurs, the lockstep block can shut down the failing core to avoid the output of erroneous signals to the remainder of the verification system. If a data mismatch as between the cores occurs (i.e., core divergence), the lockstep block can signal a system-wide alert to prevent system data corruption in that it is not known which of the cores is failing and which is operating correctly.
Within the verification system, some signals output from the lockstep block propagate to chip pads (or pins). Due to the fact that such signals may traverse circuitous paths through various different clock domains, the time at which such a signal will reach the pad is indeterminate, i.e., the arrival time cannot be determined with certainty at the time the signal is output. Given that it is important that the correct signal changes occur at the chip pads, it is desirable to confirm that those changes in fact occur. Unfortunately, however, the indeterminate nature of the signal timing renders it difficult to make that confirmation.